OPC Studio User's Guide and Reference
OPC UA Endpoint Selection Policy
Fundamentals > Common Fundamentals > Common Data Model > Identifying Information in OPC UA Client-Server > OPC UA Server Endpoints > OPC UA Endpoint Selection Policy
In This Topic

The OPC UA Endpoint Selection Policy allows you to specify the criteria that QuickOPC will use when picking up the endpoint from those made available by the target OPC UA server.  

Purpose

Why do we need the endpoint selection policy, with so many settings it has? Wouldn't it be better to specify the endpoint precisely, the same way as many other products do?

The answer to this is that in some cases, specifying the endpoint precisely may be possible and suitable. This is when you do know the endpoint parameters upfront, and you are sure that it will not change in the future. OPC Studio products actually support this approach as well (using the very same endpoint selection policy mechanism, and specifying precise parameters).

In most cases, however, the aim of the applications based on OPC Studio is to be flexible, and be able to connect to the target server not just now, but even in future, when the details of the communication may change. This can happen easily, for example, when certain encryption algorithm becomes outdated, and the server is updated to no longer support it (or to give it less preference). If you had hard-coded the precise endpoint parameters into the client application, the solution will stop working at this point, and the client application will have to be rebuilt (or reconfigured, if you had allowed for that). With endpoint selection policy properly specified to indicate your intent, the client application written with QuickOPC will automatically select the endpoint that uses the newer encryption algorithm, without anybody having to rewrite or reconfigure it.

If you use the endpoint selection policy just to express what you want to achieve, instead of picking the precise parameters which may change in future, you make your application more flexible and robust. Doing it this way is in line with the declarative approach used wherever possible in QuickOPC - that is, you express what you want to achieve, and leave the how of actually doing it to the component.

Effective Endpoint Selection Policy

The endpoint selection policy which is actually used for a concrete connection is called effective endpoint selection policy. It is determined in following steps:

  1. If the EndpointSelectionPolicy Property on the UAEndpointDescriptor is set to a non-null value, this policy will be used.
  2. Otherwise, if the Isolated Property on the EasyUAClient is true, the policy from EasyUAClient.IsolatedParameters.SessionParameters.EndpointSelectionPolicy will be used.
  3. Otherwise (if the Isolated Property on the EasyUAClient is false, which is the default), the policy from static EasyUAClient.AdaptableParameters.SessionParameters.EndpointSelectionPolicy will be used.

Endpoint Selection Algorithm

When OPC Studio selects an endpoint, it first decides whether each of the endpoints provided by the server is eligible for selection, using the effective endpoint selection policy. Settings in the Filter category (see further down) can influence this process.

The endpoint is then selected from those that have passed the filtering. What constitutes the "best" endpoint is determined by settings in the Order category (see further down).

Finally, some of the selected endpoint parameters may be modified, mainly for security reasons. This part is influenced by the settings in the Transform category (see further down).

Settings Category: Filter

Settings in this category influence which endpoints are eligible for selection. You can specify a subset of settings, and depending on how you do it, the filter may allow multiple endpoints, or just one. In some cases, the settings may conflict, and the policy would then not be able to select any endpoint ever.

Precise endpoint selection

You can specify a precise endpoint by setting following three properties of the endpoint selection policy:

More details to the values of these properties are given below.

The AllowedMessageSecurityModes property of the UAEndpointSelectionPolicy gives you a possibility to completely enable or disable certain classes of endpoints from selection, based on their security mode. You can combine the value of this property from following flags:

The UAEndpointSelectionPolicy.SecurityPolicyUriString property, when not an empty string (empty string is the default), specifies the required security policy URI string of the endpoint. This allows the developer to select the precise security policy, when so required. The static UASecurityPolicyUriStrings class contains strings that can be used to specify the security policy URI.

The TransportProfileUriString Property (when not an empty string) specifies the required transport profile of the endpoint. The static UATransportProfileUriStrings Class contains strings that can be used to specify the transport profile URI.

Imprecise endpoint selection

The endpoint does not have to be specified precisely. You can leave one or more of the settings described under "Precise endpoint selection" above - for example, keep the SecurityPolicyUriString Property and/or the TransportProfileUriString Property empty. Or, you can use combinations of multiple flags in the AllowedMessageSecurityModes Property. There are also pre-defined symbolic values for combinations of these flags, such as All (which is the default setting), or Secure.

If you want to specify some aspects of the transport profile, but not the precise transport profile as such, you can use:

ProtocolName Property: When not empty, requires the endpoint to use the specified protocol. Valid values are e.g. "HTTP", "HTTPS" or "TCP".

DataEncodingName Property: When not empty, requires that the endpoint uses the specified data encoding. Valid values are e.g. "Binary" and "XML".

Additional properties that influence the endpoint selection are:

The mechanism described here allows you to describe the intended capabilities of the endpoint, but without specifying its configuration precisely. This is the recommended approach, because it has a built-in flexibility to cover changes in server configuration or version, protocol improvements etc. An alternative approach (described above) allows more precision, but does not adapt so well to changes in server configuration. 

Requiring security objectives

Following the declarative approach, you may decide to simply state which security objectives you want to achieve, using following properties:

The communication parameters are considered as a whole. For example, even when the OPC UA message security does not provide encryption, the encryption may be provided by the transport. This is the case e.g. with the transports based on the HTTPS protocol.

Requiring certain security objectives may be combined with other settings in the policy. 

Settings Category: Order

When more than one endpoint passes the filtering, settings in the Order category influence which of these endpoints will get selected. The endpoint are given a numerical ranking, and the endpoint will the highest ranking will become the winner. The basis for the ranking is the security level of each endpoint, as indicated by the server itself. The security level can then optionally be further manipulated.

The MessageSecurityPreference property of the UAEndpointSelectionPolicy tells the component whether endpoints that provide message security are preferred for selection. It has three possible values:

Settings Category: Transform

Settings in this category influence how the endpoint parameters are modified after the endpoint has been selected. The available settings are:

The modifications are done mainly for security reasons.

Predefined Endpoint Selection Policies

Instead of setting the individual parameters of the policy, you can also use one of the predefined policies provided by the component. They are made available by static properties on the UAEndpointSelectionPolicy Class. They are:

Alternatively, parameters of the policy object can be changed to one these predefined policies by settings its StandardName Property to one of the names listed above. This is useful e.g. on the COM platform, where static properties do not exist.

 

See Also

Recommended

Reference

Concepts